1. Field of the Invention
This invention is related to application performance on a computing device. Specifically, but not intended to limit the invention, embodiments of the invention are related to parallel compilation and execution of JavaScripts in a web browser on a computing device.
2. Relevant Background
JavaScripts are often sequentially compiled and executed by JS engines such as, but not limited to, JIT-based JS engines, one by one as they appear in the file containing the JavaScript source code. For example, web browsers and a rendering engine (i.e., WebKit) may sequentially compile and execute JavaScripts in the order they appear in a base-level web page object—such as, but not limited to, a HTML file. Whenever the browser/WebKit finds a JavaScript while the HTML document is being parsed, the browser/WebKit may pass the JavaScript to the JS Engine (i.e., V8) and await the completion of compilation and execution of the JavaScript before the browser/WebKit sends the next-encountered JavaScript to JS Engine for similar processing.
Even though there may be mechanisms that allow a HTML parser to continue to download resources (such as, but not limited to JavaScripts, CSS objects, and images) during JavaScript processing, the processing of a web page is inherently a sequential lazy-evaluation of JavaScripts in web pages. This sequential processing delays HTML download, parsing and overall page loading performance. This sequential processing delay is especially noticeable for websites where a JavaScript calls another JavaScript which calls another JavaScript and so forth. Such dependency trees are becoming increasingly common, and in such embodiments, the download, then compile, then execution of a first JavaScript in the dependency tree blocks the downloading of the second JavaScript in the tree, which blocks the downloading of the third JavaScript . . . and so on.
Evaluation of JavaScripts forms a substantial part of a browser's overall page load time. Without considering networking delays, the amount of time spent processing and evaluating JavaScripts may comprise about 30% of a total a page load time when first requesting a website with a nominal amount of JavaScripts. In one traditional function-based JIT JavaScript engine, the 30% may be further partitioned into about 10% for compilation and about 20% for execution of the JavaScript.
Many limitations in JavaScript processing may be due to features such as, but not limited to, a complex inter-dependency of the JavaScripts files, JavaScripts closure feature, global variables that may be defined in various locations (i.e. anywhere), and access of share components outside the JavaScript engine that may be modifiable through a JavaScript—like a shared DOM (Document Object Model). Limitations may also be due to events that may result in a subset of JavaScripts to be evaluated (compiled & executed). It is beyond the means of current JavaScript evaluators (compilers and executors) to manage such complex interdependencies, shared DOM resources, and subsequent events that may result in subsequent JavaScript evaluation in determining an order of JavaScript evaluation. Therefore, although a non-sequential JavaScript evaluation process may lead to quicker web-page processing, current JavaScript evaluators are unable to utilize non-sequential JavaScript processing.
Furthermore, although the HTML5 <worker> tag may be used to specify that a JavaScript can be executed asynchronously on a separate thread, the tag can only be used for HTML5 implementations and oftentimes may not used by website developers. Even if it is supported by a browser that supports handling the <worker> tag, if the website doesn't use the <worker> tag, then the browser can't run JavaScripts on separate threads. Additionally, since a thread established from a <worker> tag is generally used for running a compute intensive JavaScript snippet that doesn't modify a DOM, it may not be able to handle any arbitrary JavaScript code found in a web page.